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1  Introduction 

The  Next  Generation  Computer  Resources  (NGCR)  Program  is  to  provide  the 
standardization  of  Navy  mission  critical  computer  interfaces  and  computer  component  interfaces.  With 
these  standardized  interfaces,  industry  will  be  better  able  to  provide  computing  resources  that  meet 
Navy  needs.  The  interface  standards  are  to  be  widely  available  (i.e.,  non-proprietary)  and,  if  possible, 
widely  utilized  within  industry. 

The  Project  Support  Environment  Interface  Standard  (PSEIS),  the  subject  of  this  paper,  is 
one  of  the  set  of  standards  which  is  essential  to  the  timely  and  cost  effective  acquisition  of  the  majority 
of  the  next  generation  of  Navy  mission  critical  computing  systems.  PSEIS  will  assist  the  Navy  in 
efficiently  providing  systems  which  address  a  wide  range  of  performance  levels,  compatible  computing 
service  levels,  and  functionality  levels. 

The  purpose  of  this  paper  is  to  articulate  initial  thinking  regarding  the  issues  facing  the  NGCR 
Project  Support  Environment  Working  Group  (PSEWG)  and  to  provide  a  starting  point  for  PSEWG 
discussions  when  the  group  is  initiated  in  FY-91.  This  paper  is  a  required  deliverable  under  current 
NADC  tasking  for  NGCR. 

2  Scope 


The  NGCR  interface  standards,  while  being  incrementally  developed,  are  to  be  sufficiently  in 
place  so  that  the  Navy  can  begin  acquiring  systems  utilizing  those  standards  by  1998. 

The  period  of  PSEI  standards  development  begins  in  FY91  and  continues  through  FY98.  The 
initial  PSE  standards  will  be  available  for  use  in  acquisitions  starting  in  FY95. 

The  initial  range  of  applications  includes  as  many  types  of  computing  as  possible  from  just 
above  the  single  dedicated  processor  to  as  high  as  can  be  obtained  on  networked,  heterogeneous, 
modularized  backplane  bus  architecture  computing  systems.  Networking  is 
to  be  done  using  NGCR  LAN  standards  and,  as  appropriate,  other  MIL-STD  links. 
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3  Issues 

3.1  Technical 

There  are  a  number  of  levels  at  which  NGCR  can  strive  to  establish  useful  PSE  interface 
standards.  Most  of  them  are  not  addressed  well  by  current  industry  standards.  Therefore  it  will  be 
necessary  to  carefully  choose  the  objectives  of  this  effort. 

There  are  several  areas  of  technical  concern  which  should  be  considered  during  the 
development  of  a  set  of  specifications  for  a  set  of  project  support  environment  interface  standards. 
Some  of  the  major  areas  of  concern  are  listed  below  with  a  brief  description.  They  are  considered 
essential  characteristics  of  the  support  environment. 

The  following  list  is  not  in  any  particular  order. 

3.1.1  Possible  Goals 

A  number  of  different  goals  for  the  PSEI  are  possible.  Some  of  them,  along  with  assessments 
of  their  praticality  for  this  effort,  are: 

1.  Being  able  to  "mix  &  match"  tools  from  different  vendors.  This  is  definitely  a  goal.  It  is  in 
the  Navy's  best  interests  to  be  able  to  acquire  tools  competitively  from  a  variety  of  sources. 

2.  Minimizing  training.  This  is  also  very  desirable.  It  is  achieved  by  standardizing  those  aspects 
of  the  PSE  which  affect  the  ability  of  a  PSE  implementer  (i.e.,  tool-  or  framework-writer)  or  user  (e.g., 
a  programmer  using  the  PSE  to  generate  code  for  an  application)  to  move  from  one  NGCR- 
conforming  PSE  to  another.  This  consideration  expands  the  concern  of  the  standardization  beyond  just 
the  tools  and  into  the  framework  and  user  interface  aspects. 

3.  Maximizing  ease  of  transition  to  PDSS.  This  is  poorly  addressed  in  today’s  scheme  of 
handing  things  off  from  a  contractor  to  a  Navy  agency  or  from  a  Navy  laboratory  to  a  PDSS  agent  for 
system  maintenance.  It  is  an  important  concern  and  needs  to  be  addressed  by  these  standards.  This 
suggests  an  emphasis  on  generation  and  delivery  of  project  databases  and  commonality  among  facilities 
used  by  contractors,  laboratories,  and  maintenance  activities. 

4.  Maximizing  tool  commonality  (e.g.,  "common  buys")  vs.  achieving  a  higher  level  (e.g., 
framework)  of  standardization  vs.  both.  A  current  approach  to  standardization  of  Navy  PSEs  takes 
advantage  of  the  economy  that  can  be  had  by  the  laboratories  agreeing  to  purchase  certain  useful  tools 
cooperatively;  this  eliminates  all  of  the  redundant  decision-making,  evaluation,  and  expense  of  fees  and 
royalties.  However,  it  would  be  quite  difficult  to  bring  together  as  large  a  community  as  the  entire  Navy 
under  such  a  scheme,  largely  because  of  the  great  diversity.  It  would  be  better  to  establish  the  common 
interfaces  on  which  such  a  strategy  could  be  based  than  to  essentially  try  to  standardize  on  certain 
jointly  agreed  tools;  with  common  interfaces,  certain  Navy  sub-communities  who  found  advantage  in 
such  a  "common  buy"  could  do  so  even  more  readily  than  today. 

5.  Achieving  host  interchangability.  It  is  clear  that  the  Navy  needs  to  be  independent  of  various 
hardware  vendors.  In  particular,  it  is  desirable  for  a  Navy  activity  to  be  able  to  change  from  one  host 
system  to  another  without  negative  impact  on  all  of  the  PSE  investment  they  have  made.  In  addition, 
the  interfaces  should  not  be  dependent  on  the  use  of  hardware  from  only  one  vendor. 

6.  Attaining  a  particular  level  in  the  SEI  assessment.  It  is  not  clear  to  what  extent  the  levels  in 
the  SEI  assessment  affect  the  PSE  interfaces.  But  to  whatever  extent  they  do,  the  PSE  interfaces  should 
not  preclude  an  organization's  ability  to  achieve  the  highest  level. 
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7.  Achieving  compatibility  with  other  NGCR  standards.  It  is  very  important  that  all  of  the 
NGCR  standards  cooperate  and  appear  compatible  to  users.  For  the  PSEI,  this  is  especially  important 
in  its  relationship  with  the  OSIF,  since  most  of  its  interaction  will  be  with  the  OS. 

3.1.2  Scope 

The  scope  of  the  environment  (and  therefore  of  the  resulting  standards)  also  needs  to  be 
carefully  considered. 

1.  Is  the  PSE  only  intended  to  support  the  generation  of  software,  or  should  it  be  able  to 
support  other  aspects  of  system  development  as  well,  such  as  GAD/CAM?  Several  efforts  point  to  the 
fact  that  there  is  very  little  difference  between  the  underlying  support  required  for  the  support  of 
software  and  that  required  for  the  support  of  hardware  and  general  systems  work.  In  fact,  the  ability  to 
provide  PSEs  which  fully  support  both  software  and  hardware  design  and  development  would  be  very 
positive,  as  it  would  provide  an  opportunity  for  true  systems  engineering  to  take  place  in  a  common 
environment.  Activities  that  are  necessary  for  good  systems  engineering,  such  as  hardware/software 
trade-offs,  could  then  become  a  part  of  normal  systems  development  work. 

2.  Should  the  programming  languages/paradigms  supported  be  only  for  Ada,  or  should  a 
variety  of  languages  be  supported?  Ada  is  the  language  of  choice  for  MCCR  for  the  DoD,  so  it  must 
certainly  take  a  prominent  place  in  the  PSE.  However,  there  are  legitimate  reasons  for  including  a 
variety  of  languages.  Many  tools  that  will  be  available  off-the-shelf  in  the  near  future  will  be  written  in 
languages  other  than  Ada,  but  the  Navy  needs  to  be  able  to  take  advantage  of  these.  In  addition,  some 
applications  in  the  future  will  use  special-purpose  languages,  such  as  artificial  intelligence  and  fourth 
generation  languages,  which  the  PSE  will  also  be  called  upon  to  support. 

3.  What  is  the  application  mix  which  is  to  be  supported?  There  is  a  wide  range  of  Navy 
applications,  from  those  resembling  business  systems  to  those  that  typify  the  extreme  in  demands  for 
such  attributes  as  security,  fault  tolerance,  and  hard-real-time.  The  PSE  must  be  able  to  support  this 
range  of  applications.  That  implies  that  various  suites  of  tools,  including  those  that  place  an  emphasis 
on  space/time  trade-offs  for  small  platforms,  will  be  required,  and  the  characteristics  of  the  PSEs 
which  can  be  built  using  the  PSEIF  will  have  to  be  able  to  change  to  meet  these  needs.  The  PSEs  must 
be  flexible  and  evolvable,  so  the  PSEIF  must  also  display  these  attributes. 

3.1.3  Level/Extent  of  Standardization 

There  are  many  different  ways  in  which  PSE  standardization  can  be  approached.  Among  them 

are: 


1.  Choose  a  standard  set  of  tools.  This  has  the  advantage  of  achieving  economies  at  purchase 
time,  but  it  has  the  liability  of  locking  in  what  could  quickly  become  outdated  technology  and  of  locking 
in  the  vendors  of  the  chosen  products.  These  liabilities  are  contrary  to  the  objectives  of  NGCR. 

2.  Choose  an  OS,  DBMS,  etc.  This  has  the  advantage  of  establishing  a  common  platform,  but 
does  not  address  all  of  the  other  functionality  which  it  takes  to  make  a  true  PSE.  It  also  has  the 
liabilities  discussed  above  for  choosing  a  standard  set  of  tools. 

3.  Standardize  on  interfaces  which  are  key  to  the  PSE  framework.  The  framework  consists  of 
those  aspects  of  a  PSE  which  exceed  the  hardware/software  "platform"  and  the  tools  which  do  the 
specific  functions.  It  encompasses  a  central  data  repository  for  the  retention  of  project-related 
information  and  the  means  which  can  therefore  be  made  available  for  integration  of  project 
management  and  technical  process.  This  alternative  is  consistent  with  NGCR's  approach  of  interface 
standardization. 
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The  consensus  of  the  community  is  that  the  best  approach  to  PSC  standardization  is  through 
the  standardization  of  various  interfaces.  The  exact  identification  of  the  interfaces  which  will  be 
required  to  achieve  the  goals  of  NGCR  in  the  area  of  PSEs  will  be  one  of  the  initial  tasks  of  the 
PSEWG. 

3.1.4  User  Interface 

The  user  interface  has  many  different  aspects,  some  of  which  are  the  subject  of  what  might  be 
appropriate  standardization  efforts  (e.g.,  GKS,  X-Windows)  and  some  of  which  do  not  appear  to  be 
(e.g.,  consistent  commands  for  common  actions  such  as  termination).  The  PSEWG  must  take  care  to 
identify  the  various  aspects  of  user  interfaces  and  to  become  familiar  with  relevant  efforts.  At  the  very 
least,  the  PSE  standard  must  be  capable  of  providing  support  for  sophisticated  color,  bit-mapped, 
image-oriented  graphics. 

It  should  be  noted  that  the  NGCR  program  proposes  to  establish  a  Graphics  Language 
standard  for  target  applications,  so  one  can  consider  whether  or  not  this  should  be  required  to  also  be  a 
part  of  the  PSE  user  interface  standardization.  The  recommendation  is  that  the  PSEWG  first  identify 
the  graphics-related  needs  of  the  PSE;  then,  if  the  NGCR  Graphics  standard  appears  to  apply  to  the 
PSE  as  well,  choosing  it  might  be  advantageous.  But  no  a  priori  determination  should  be  made  that  the 
two  must  be  compatible. 

3.1.5  Information  Management 

Information  management  is  critical  to  a  PSE.  But  there  is  little  understanding  yet  of  what  this 
entails,  and  there  are  even  fewer  existing  or  proposed  standardization  efforts  which  attempt  to  address 
this.  Certainly  it  is  related  to  questions  of  database  management,  but  it  goes  far  beyond  what  a  typical 
database  management  system  can  provide  alone. 

There  are  also  issues  regarding  what  level  of  granularity  of  information  should  be  retained  in 
the  information  management  system.  On  the  one  hand,  projects  have  the  need  to  retain  gross  level 
objects  such  as  source  code  programs  and  design  documents.  On  the  other,  projects  (particularly 
individuals  within  projects)  have  the  need  to  retain  detailed  information  about  parts  of  these  larger 
objects,  such  as  the  relationship  between  a  module  and  its  test  cases  or  between  a  design  element  and 
the  requirement  which  it  fulfills.  These  varying  levels  of  granularity  raise  the  question  of  whether  a 
single  common  information  management  system  should  be  expected  to  address  all  of  them.  Perhaps  a 
bi-level  system  should  be  investigated  in  which  objects  at  the  gross  level  are  at  the  higher  level  of  the 
information  management  system  and  the  detailed  information  about  elements  of  those  gross-level 
objects  are  contained  in  a  related  information  management  system  which  might  be  better  capable  of 
supporting  the  demands  of  the  lower-level,  finer-grained  objects  and  operations. 

As  with  the  Graphics,  the  NGCR  program  proposes  to  establish  a  Data  Base  Management 
System  standard  for  target  applications,  so  one  can  consider  whether  or  not  this  should  be  required  to 
also  be  a  part  of  the  PSE  information  management  standardization.  The  recommendation  is  that  the 
PSEWG  first  identify  the  information-related  needs  of  the  PSE;  then,  if  the  NGCR  DBMS  standard 
appears  to  apply  to  the  PSE  as  well,  choosing  it  might  be  advantageous.  But  no  a  priori  determination 
should  be  made  that  the  two  must  be  compatible. 

3.1.6  Methodology  Support 

Since  many  users  equate  a  PSE  with  the  tools  it  contains  and  these  often  embody  support  for 
specific  methodologies,  the  ideas  of  what  the  environment  should  do  in  the  way  of  methodology  and 
what  the  tools  can  do  are  often  confused.  A  PSE  should  be  capable  of  supporting  any  responsible 
methodology  which  a  project  might  choose  to  employ,  provided  the  project  can  acquire  the  tools 
necessary  to  support  the  chosen  methodology.  However,  beyond  this,  there  are  some  general  ways  in 
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which  a  PSE  can  be  more  or  less  conducive  to  various  approaches.  For  example,  it  could  be  as  generic 
as  possible  or  it  could  pre-determine  that,  although  a  variety  of  approaches  are  allowed,  they  must  all 
be  some  variation  on  transformational  programming.  It  is  believed  that  such  a  restriction  would  be 
unnecessary  and  counter-productive,  since  no  definitive  answer  has  materialized  as  yet  to  the  question, 
"what  is  the  best  methodology?"  However,  those  deciding  on  the  interface  standards  to  be  adopted 
should  be  careful  not  to  adopt  any  which,  either  individually  or  in  combination,  inadvertently  limit  the 
options. 


Another  aspect  of  methodology  is  support  for  such  paradigms  as  re-use  and  automatic 
generation  of  code.  Both  of  these  have  important  roles  to  play  in  the  development  of  future  Navy 
systems,  so  both  should  be  accommodated  but  neither  should  be  forced  on  everyone. 

Finally,  the  PSE  is  in  a  unique  position  to  assist  project  managers  in  the  planning  and  tracking 
of  project  plans  and  the  enforcement  of  project-chosen  process  guidelines.  While  it  is  possible  to 
include  in  the  PSE  standards  one  for  a  standard  overall  project  process,  that  is  undoubtedly  premature. 
But  the  PSE  should  be  capable  of  accommodating  a  variety  of  such  processes  and  of  enforcing  those 
aspects  which  the  manager  choses  to  have  it  enforce. 

3.1.7  Integration 

Overall  integration  of  tools,  data,  and  users  is  one  of  the  key  functions  of  the  PSE.  It  can  be 
achieved  at  a  variety  of  levels,  all  of  which  are  important.  One  of  the  key  ones  is  integration  of  data  and 
process,  such  that  information  flows  smoothly  between  tools  and  between  technical  project  workers 
and  the  project  management.  Another  key  one  is  that  of  integration  of  style,  particularly  of  the  user 
interface  across  a  variety  of  tools  and  capabilities.  A  third  is  the  integration  of  tools  from  a  variety  of 
sources  into  the  PSE  in  such  a  way  as  to  provide  a  seamless  environment  while  still  taking  advantage  of 
products  from  a  variety  of  vendors.  All  of  these  integration  goals  place  extraordinary  demands  on  the 
PSE  and  on  the  interfaces  which  are  standardized. 

3.1.8  Transition  from  Today’s  Environments 

Transition  from  the  state-of-the-practice  of  today  to  the  system  generation  approaches  which 
will  be  guided  by  NGCR  is  an  important  consideration  in  all  aspects  of  the  NGCR  program.  Two 
particular  aspects  are  important  to  the  PSE.  One  is  the  capture  of  existing  significant  systems  of  tools, 
most  particularly  Ada  compilation  systems.  Many  tools  which  might  do  quite  well  for  the  Navy  are 
currently  available,  but  not  in  the  context  of  true  PSEs.  It  must  be  possible  to  move  these  current  tools 
into  PSEIF-based  environments  quickly  and  economically  in  order  for  the  marketplace  to  find  it 
feasible  to  support  (i.e.,  market  tools  and  capabilities  which  are  compliant  with)  the  NGCR  standards. 
This  is  likely  to  place  some  constraints  on  the  interfaces  which  can  be  standardized. 

Another  consideration  for  transition  is  how  to  help  organizations  move  from  existing  Navy 
environments  (e.g.,  ALS/N)  to  new  NGCR-based  environments.  Such  transition  scenarios  must  be 
well-understood  before  decisions  can  be  made  regarding  PSE  interface  standardization. 

It  is  likely  to  be  more  effective  to  think  in  terms  of  transition  and  to  plan  from  the  start  to 
furnish  appropriate  transition  guideline  documents  than  it  is  to  let  too  many  of  these  considerations 
hamper  the  interfaces  themselves.  Transition  is  not  the  top-priority  concern  for  the  PSE,  but  some 
thinking  about  it  at  the  beginning  is  likely  to  save  a  lot  of  trouble  at  the  end. 

3.1.9  Distribution  /  Networking 

Distribution  and  networking  appear  to  be  a  fact-of-life  in  todays'  environments  and  would 
seem  to  have  an  ever-increasing  role  for  the  future  of  PSEs.  But  distribution  can  take  several  different 
forms,  and  the  PSEWG  needs  to  be  aware  of  them. 
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One  concern  is  the  difference  between  the  "distributed  workstation"  vision,  where  everyone  has 
a  workstation  at  their  desk  and  there  are  no  large  mainframes  involved,  and  the  "mainframe  with 
intelligent  terminals"  vision,  which  more  closely  resembles  some  of  the  software  support  capabilities  of 
today.  Both  are  and  will  continue  to  be  important,  but  assumptions  associated  with  each  one  must  be 
considered  together  or  incomplete  interfaces  will  result. 

As  with  the  Graphics  and  DBMS,  the  NGCR  program  has  already  taken  steps  to  establish  a 
Local  Area  Network  standard  (called  SAFENET)  for  target  applications,  so  one  can  consider  whether 
or  not  this  should  be  required  to  also  be  a  part  of  the  PSE  standardization.  The  recommendation  is 
that  the  PSEWG  first  identify  the  network-related  needs  of  the  PSE;  then,  if  SAFENET  appears  to 
apply  to  the  PSE  as  well,  choosing  it  may  be  advantageous.  But  no  a  priori  determination  should  be 
made  that  the  two  must  be  compatible. 

Another  interesting  question  raised  by  the  other  NGCR  standards  concerns  the  existence  of 
the  backplane  standard,  based  on  Futurebus+ .  What,  if  any,  impact  will  this  have  on  the  PSE  and  on 
the  architectures  on  which  it  will  depend?  To  what  extent  should  a  backplane  standard  be  taken  into 
account  in  the  derivation  of  the  PSE  interfaces?  These  questions  and  others  like  them  remain  to  be 
dealt  with  and  resolved  for  the  PSEIF. 

In  addition  to  the  issues  raised  by  a  standard  backplane,  one  must  consider  other  sorts  of 
hardware  technology  which  appear  to  be  coming  up  on  the  horizon  and  determine  whether  or  not  they 
need  to  be  taken  into  account  when  standardizing  PSE  interfaces.  Examples  of  these  are 
supercomputers  and  array/parallel  processing.  Again,  these  must  be  considered,  and  in  two  ways  for 
the  PSE:  both  for  their  effects  as  elements  in  the  PSE  host  environment  and  as  parts  of  the  target 
configurations  for  which  the  PSE  will  help  develop  systems. 

3.1.10  Heterogeneity  of  Functions  /  Processing  Elements 

The  PSE  must  be  implementable  on  a  heterogeneous  platform  of  hardware  in  a  variety  of 
architectures  and  configurations  to  allow  for  the  incorporation  of  new  technology  and  new  system 
development  requirements.  This  supports  one  of  the  NGCR  objectives  which  is  to  avoid  dependencies 
on  proprietary  products.  Heterogeneity  should  be  supported  at  many  levels.  Support  for  standard 
programming  languages  such  as  Ada  increases  program  portability.  Possibly  inconsistent  object 
formats  present  a  problem  that  needs  to  be  considered.  The  ability  to  convert  data  representations 
between  a  variety  of  targets  is  an  important  consideration  as  well.  Many  other  areas  of  the  PSE  also 
need  to  be  considered  in  terms  of  heterogeneity. 

3.1.11  Recovery  /  Damage  Control/  Fault  Tolerance  /  Survivability 

Although  Fault  Tolerance  is  not  as  vital  a  consideration  in  the  PSE  as  it  is  in  the  target 
environment,  it  is  still  important  and  should  be  addressed  by  the  PSEWG.  Perhaps  it  does  not  affect  so 
much  the  PSE  interfaces  themselves  as  it  does  the  choices  which  one  makes  in  selecting  the 
characteristics  of  the  underlying  platforms.  The  PSE  must  also  be  capable  of  supporting  these 
characteristics  in  the  target  applications  which  it  is  used  to  generate,  so  these  considerations  may  have 
some  additional  impacts  on  the  PSE  interfaces. 

3.1.12  Security 

Since  the  PSE  must  be  able  to  support  the  generation  of  secure  systems,  it  must  be  able  to 
protect  its  own  integrity  from  inadvertent  or  malicious  misuse.  The  PSE  should  support  multi-level 
security  within  a  singular  PSE  as  well  as  across  a  distributed  architecture.  The  security  mechanism 
should  conform  to  available  and  evolving  DoD  standards  as  appropriate.  Security  is  a  particularly 
difficult  issue  to  solve  when  coupled  with  the  response  requirements  of  interactive  systems. 


6 


NADC-901 03-70 


3.1.13  Application-specific  Environments 

Although  the  PSE  standards  need  to  be  generic,  projects  will  sometimes  find  the  need  to  tailor 
their  environments  to  the  specific  needs  of  a  particular  application  area.  The  PSE  standards  should 
recognize  this  and  facilitate  it.  Generally  this  applies  to  the  choice  of  tools,  but  it  can  be  reflected  in 
other  aspects  such  a  support  for  the  project-chosen  process  and  for  re-use  of  application-specific 
modules. 

3.1.14  Relationship  to  OS 

One  of  the  most  important  relationships  that  the  PSE  has  with  the  other  NGCR  standards  is 
with  the  operating  system.  Some  desirable  operating  system  characteristics  have  already  been  identified 
which  require  the  PSE's  support  in  order  to  realize.  Chief  among  these  is  the  desire  to  have 
configurable  implementations  of  the  operating  system  interface  standard.  This  entails  the  population  of 
a  library  with  NGCR  operating  system  interface  standard-compliant  operating  system  elements  which 
can  be  combined  in  a  variety  of  ways  to  meet  the  peculiar  needs  of  a  given  application;  for  example, 
although  modules  which  provide  full  support  for  a  file  system  would  be  present  in  the  operating  system 
library,  an  application  which  did  not  have  any  need  for  a  file  system  would  need  to  be  able  to  configure 
an  operating  system  implementation  which  did  not  include  these  modules  and  would  still  provide  all  of 
the  other  aspects  required  for  that  application. 

In  addition,  close  communication  and  cooperation  between  the  operating  system  and  the  PSE 
must  be  possible  in  order  to  achieve  down-loading  of  application  programs  to  the  target  and  target 
debugging. 

3.2  Policy 

It  is  the  NGCR  policy  to  adopt  existing  commercial  standards  whenever  possible.  The  world  of 
PSE-related  standards  is  quite  bewildering,  as  there  are  a  number  of  standards  which  would  seem  to  be 
applicable,  but  it  is  clear  that  there  is  no  common  vision  coordinating  them,  such  as  the  OSI  reference 
model  does  for  the  world  of  LANs.  This  makes  it  extraordinarily  difficult  to  determine  either  which 
standards  might  be  adopted  together  to  achieve  some  goal  or  where  there  are  holes  or  gaps  where  no 
standardization  activity  has  started.  It  will  be  a  critical  step  in  the  establishment  of  the  PSE  interface 
standards  first  to  establish  a  reference  model  which  can  help  to  bring  some  sense  out  of  the  chaos  and 
then  to  unravel  the  maze  of  efforts  and  put  them  into  some  context  with  respect  to  this  model. 

It  will  also  be  important  for  NGCR  to  carefully  consider  what  the  Navy’s  policies  should  be 
with  respect  to  the  mandate  of  the  adopted  PSE  interface  standards.  A  "carrot-and-stick"  approach  (as 
opposed  to  a  strictly  "stick”  one)  would  undoubtedly  be  most  effective  in  an  area  such  as  the  PSE  in 
which  there  is  a  great  deal  of  change  happening  and  very  little  maturity  of  any  current  products  or 
efforts. 
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4  Approach 

The  primary  objective  of  the  PSEWG  will  be  the  development  of  a  set  of  interface  standards 
for  project  support  environments.  In  support  of  this  objective,  it  will  also  be  necessary  to  generate  a 
variety  of  accompanying  documents,  including  at  least  the  following: 

operational  concept/reference  model 

requirements  (with  rationale) 

rationale  for  the  set  of  interface  standards 

user  and  implementer  guides 

It  will  also  be  critical  to  the  success  of  the  effort  to  be  able  to  demonstrate  the  viability  of  the  proposed 
standard  through  prototype  implementations.  As  the  NGCR  budget  currently  stands,  no  money  is 
planned  for  such  an  effort,  so  it  must  be  achieved  through  cooperation  with  other  projects  and 
cooperative  use  of  available  resources. 

The  PSEWG  should  have  primary  responsibility  for  all  decisions  made  with  respect  to  the 
project  support  environment  interface  specification  and  accompanying  products.  It  should  be 
structured  analogously  to  the  existing  NGCR  working  groups,  with  a  Navy  Chairman  and  Co- 
Chairman  and  a  mixture  of  government,  university  and  industry  participants.  Meetings  should  be  at 
least  quarterly,  possibly  supplemented  by  more  frequent  meetings  of  individual  subgroups. 

Before  the  PSEWG  is  first  convened,  the  Navy  laboratories,  under  the  leadership  of  NADC, 
will  do  further  planning.  This  planning  should  further  develop  and  elaborate  on  the  suggestions 
presented  here  for  organization,  issues  and  products.  The  first  PSEWG  meeting  should  be  attended  by 
only  government  personnel.  This  is  to  ensure  coherence  and  direction  of  the  government  objectives  and 
requirements  prior  to  exposure  of  these  to  the  general  community.  Such  an  initial  government  meeting 
can  be  pursued  in  parallel  with  the  solicitation  of  initial  information  from  industry  and  universities. 

Government  participants  should  be  solicited  from  at  least  each  of  the  Navy  laboratories  and 
PDSS  activities.  Other  sources  of  relevant  expertise  should  also  be  investigated  and  tapped  if  possible, 
including  Navy  testing  activities,  development  and  PDSS  organizations  from  the  other  services,  and 
other  federal  agencies,  such  as  DARPA,  NASA,  JIAWG,  and  NIST. 

Industry  and  university  participants  should  be  solicited  both  from  known  sources  and  through 
open  solicitations  such  as  in  the  CBD. 

It  should  be  assumed  both  that  the  government  does  not  have  suificieLt  qualified  personnel 
by  itself  to  successfully  complete  this  project  and  that  volunteers  (whether  from  government,  university 
or  industry)  cannot  be  expected  to  be  sufficiently  regular  or  dependable.  Thus  plans  should  be  made  to 
have  two  kinds  of  support  contracts.  One  would  be  administrative/secretarial  in  nature,  the  other 
technical.  The  technical  "contract"  could  in  fact  be  several  contracts,  each  for  a  different  sort  of 
expertise,  or  it  could  be  one  contract  awarded  to  a  sufficiently  diverse  team. 

The  PSEWG  should  be  free  to  form  subgroup  structures  as  they  are  needed.  These  will  most 
likely  respond  to  different  needs  at  different  stages  in  the  life  of  the  PSEIS  activity.  Initially  it  is 
suggested  that  a  subgroup  structure  be  formed  which  is  oriented  around  the  different  kinds  of  issues 
presented  in  the  last  section.  These  issues  can  be  grouped  in  ways  which  afford  an  opportunity  for 
participants  with  similar  interests  and  backgrounds  to  discuss  a  logical  group  of  related  issues  to  belter 
describe  them  and  to  get  a  better  understanding  of  their  role  in  the  entire  PSEIS  effort.  The  objective 
of  this  initial  organization  would  be  to  articulate  and  understand  the  reference  model  which  would  be 
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used  for  the  remainder  of  the  group's  activities.  Later  it  is  likely  that  a  subgroup  structure  oriented 
around  the  products  or  around  a  set  of  orthogonal  concerns  would  be  more  productive.  One  such 
structure  might  have  a  subgroup  for  each  of  Requirements,  Available  Technology  (to  meet  the 
emerging  requirements),  and  Approach  (to  formulate  processes  and  considerations  to  be  used  in 
proceeding  with  the  work). 

One  of  the  first  activities  of  the  PSEWG  should  be  the  formulation  of  a  charter.  This  activity 
will  serve  to  focus  and  channel  the  thinking  of  the  participants.  Any  subgroups  should  also  formulate 
charters  for  their  special  objectives. 


9 


N  ADC-901 03-70 


5  Available  Technology 

No  currently  existing  standard  adequately  addresses  all  of  the  PSE  concerns  discussed  above. 
However,  there  exists  a  great  deal  of  PSE-related  expertise  in  government,  universities  and  industry. 
The  level  of  work  being  done  by  these  various  groups  ranges  from  purely  theoretical  to  attempts  to 
produce  products.  The  following  is  meant  to  highlight  some  of  the  more  extensive  work  being  done  and 
is  by  no  means  to  be  considered  a  complete  list.  These  groups  could  potentially  provide  valuable 
input  to  the  development  of  PSEIS. 

5.1  Technical  Groups 

Naval  Air  Development  Center  (NADC) 

NADC  has  been  at  the  forefront  of  PSE  related  activities  for  over  15  years.  One  of  the  first 
operational  PSEs  to  demonstrate  some  of  the  features  advocated  in  earlier  sections  of  this  paper  was 
the  NADC  Facility  for  Automated  Software  Production  (FASP).  Several  project-tailored  versions  of 
the  FASP  are  still  in  use  today.  In  addition,  NADC  was  chosen  by  NAVAIR  to  lead  its  effort  to 
increase  PSE-related  commonality  among  the  Navy  laboratories  which  most  often  work  on  NAVAIR 
projects.  Called  the  NAVAIR  Software  Engineering  Environment  (NASEE),  this  project  concentrates 
on  solving  many  of  the  real  PSE  problems  which  need  to  be  addressed  in  the  near  term.  NADC 
personnel  are  also  involved  in  various  capacities  in  a  wide  variety  of  other  PSE-  related  activities.  Point 
of  contact:  Patricia  Oberndorf,  Code  7031,  NADC,  Warminster,  PA  18974-5000,  (215)441-2737. 


Naval  Ocean  Systems  Center  (NOSC) 

NOSC  also  has  a  long  history  of  involvement  in  PSE  projects  and  research.  Earlier  efforts 
have  included  one  of  the  first  attempts  to  set  out  requirements  for  a  PSE,  as  part  of  the  Software 
Engineering  Automation  for  Tactical  Embedded  Computer  Systems  (SEATECS)  project.  Until 
recently,  NOSC  was  also  responsible  for  the  ONT  Computer  Block  Program,  which  includes  a 
significant  portion  of  the  Navy's  PSE  research  activities.  Point  of  contact:  Linwood  Sutton,  Code  413, 
NOSC,  San  Diego,  CA  92152-5000,  (619)553-4082. 

Naval  Surface  Weapons  Center  (NSWC) 

NSWC  is  the  primary  support  lab  for  the  AEGIS  tactical  real-time  system.  As  such,  they  have 
a  great  deal  of  interest  and  expertise  in  PSEs  as  they  are  available  today  and  what  the  needs  are  for 
their  imprqovements  in  the  future.  Point  of  contact:  Daniel  Green,  NSWC,  Dahlgren,  VA  22448, 
(703)  663-4585. 

Naval  Underwater  Systems  Center  (NUSC) 

One  of  the  groups  at  NUSC  has  been  a  principle  contributor  the  Navy’s  Ada  Language 
System/Navy  (ALS/N)  project.  In  addition,  they  are  well-equipped  and  well-qualified  to  perform  a 
number  of  experiments  with  respect  to  PSE  issues.  Point  of  contact:  Tpm  Conrad,  NUSC,  Newport 
Laboratory,  Code  2221,  Newport,  RI  02840,  (401)  841-3846. 
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Rome  Air  Development  Center  (RADC) 

RADC  also  has  a  long  history  of  involvement  in  PSE  projects  and  research.  They  were 
responsible  for  the  Ada  Integrated  Environment  (AIE),  one  of  the  first  DoD  projects  to  address  Ada 
PSEs.  They  were  also  quite  active  in  the  DoD  Software  Technology  for  Adaptable,  Reliable  Systems 
(STARS)  program  and  in  the  Ada  Joint  Program  Office's  (AJPO)  Evaluation  and  Validation  (E&V) 
Team,  producing  a  significant  PSE  taxonomy  for  that  team.  Current  work  includes  the  Software  Life 
Cycle  Support  Environment  (SLCSE)  project.  Point  of  contact:  Frank  LaMonica,  RADC,  Griffiss  Air 
Force  Base,  NY  13441-5700,  (315)  330-2054. 

CECOM 

In  the  past,  CECOM  has  done  work  in  the  area  of  DoD  PSEs.  Most  notable  is  their  effort 
to  produce  the  Ada  Language  System  (ALS).  Point  of  contact:  Dennis  Turner,  CECOM,  Fort 
Monmouth,  NY,  (201)  554-4149. 

National  Aviation  and  Space  Agency  (NASA) 

The  National  Aeronautics  and  Space  Administration  (NASA)  Space  Station  project  is 
working  to  field  an  elaborate  space  station  facility  in  the  1990's.  The  system  will  be  highly  computer- 
dependent  and  places  significant  demands  on  the  PSE.  This  group  of  people  has  been  gathering 
information  and  experience  for  the  last  few  years  and  would  be  a  valuable  source  of  insight  into 
potential  PSEIS  issues  and  challenges.  Point  of  contact:  Ed  Chevers,  NASA  Johnson  Space  Center, 
Houston,  TX,  (713)  483-4281. 

National  Institute  for  Standards  and  Technology  (NIST) 

NIST  has  initiated  a  series  of  workshops  which  is  oriented  towards  determining  a  common 
reference  model  for  environments  and,  using  this  model,  determining  those  aspects  whose  needs 
appear  to  be  met  by  standards  and  those  which  appear  to  need  new  work  to  achieve  appropriate 
standardization.  In  addition,  NIST  has  a  long  history  of  participation  in  appropriate  standards  activities 
and  has  a  certain  amount  of  influence  with  those  organizations  which  are  pursuing  standards  that  could 
be  used  as  a  part  of  the  PSEIS.  Point  of  contact:  William  Wong,  NIST,  Gaithersburg,  MD  20899, 
(301)590-0932. 

Software  Engineering  Institute  (SEI) 

SEI  is  currently  involved  with  a  number  of  PSE-related  projects.  One  of  the  more  well- 
known  ones  is  the  work  they  have  done  to  define  a  number  of  levels  of  achievement  in  the  area  of 
software  engineering  sophistication,  resulting  in  a  tool  for  assessing  various  organizations.  The  staff 
also  includes  a  number  of  people  well-known  in  the  PSE  arena.  Point  of  contact:  Larry  Druffel,  SEI, 
Pittsburgh,  PA  15213,  (412)  268-7740. 

Kendall  Square  Research  (KSR) 

KSR  is  involved  in  several  aspects  of  PSEs,  including  both  tools  and  framework  concepts. 
Point  of  contact:  Kendall  Square  Research,  One  Kendall  Square,  Cambridge,  MA  02139,  (617)  494- 
1146. 


11 


NADC-901 03-70 


Software  Productivity  Solutions  (SPS) 

SPS  has  been  involved  in  a  number  of  PSE  activities  since  their  formulation.  These  activities 
include  participation  on  the  AJPO's  KAPSE  Interface  Team  (KIT),  developers  of  CAIS-A  (see  below), 
and  the  E&V  Team.  More  recently,  they  have  been  involved  in  a  project  to  derive  an  approach  to 
environment  assessment.  Point  of  contact:  Andy  Rudmik,  SPS,  Inc.,  P.O.  Box  361697,  Melbourne,  FL 
32936-1697,  (407)984-3370. 


University  of  Southern  California  (USC)  Information  Sciences  Institute  (ISI) 

USC-ISI  has  been  pursuing  modern  high-payoff  approaches  and  technologies  for  building 
advanced  software  environments.  Much  of  their  work  has  been  concerned  with  radically  new  paradigms 
and  supporting  environments  for  the  initial  development  and  lifecycle  evolution  of  software.  They  have 
extensive  practical  experience  in  evolution  of  approaches  to  construct  software  environments  which  are 
centered  around  databases.  As  a  result,  USC-ISI  has  developed  both  a  technology  and  an  associated 
methodology  for  constructing  data-centered  environments  and  systems.  Point  of  contact:  Bob  Balzer, 
USC  Information  Sciences  Institute,  4676  Admiralty  Way,  Marina  Del  Rey,  CA  90292,  (213)822-1511. 

Other 

There  is  other  research  and  development  in  the  area  of  PSEs.  All  of  these  groups, 
especially  the  ones  mentioned  above,  have  valuable  insight  into  environment-related  issues.  In 
particular,  most  major  vendors  are  quite  concerned  about  how  best  to  support  current  and  future 
demands  for  more  sophisticated  support  environments.  Also  included  are  the  Microelectronics  and 
Computer  Technology  Corporation  (MCC)  and  the  Software  Productivity  Consortium  (SPC),  both  of 
which  have  engaged  in  varied  forms  of  PSE-related  research  and  development. 

5.2  PSE  Projects 

STARS 

The  DoD  STARS  project  has  had  many  facets.  Although  early  efforts  resulted  in  various  levels 
of  requirements  and  specifications  for  a  common  environment,  more  recent  efforts  have  emphasized 
participation  of  industry  to  produce  a  wide  variety  of  tools  (known  as  the  Foundations  effort)  and  three 
incarnations  of  software  engineering  environments  which  will  further  the  technology  required  while 
incorporating  existing  standards  whenever  possible.  The  three  prime  contractors  are  IBM,  Boeing  and 
UNISYS.  Point  of  contact:  Dr.  Jack  Kramer,  STARS  Technology  Center,  Suite  317,  Arlington,  VA 
22209,  (703)243-8655. 

JIAWG  SEE 

The  Joint  Integrated  Avionics  Working  Group  (JIAWG)  has  been  charged  with  the 
responsibility  of  achieving  a  greater  level  of  commonality  between  the  avionics  products  of  the  three 
services,  particularly  the  ATA,  ATF  and  LHX.  One  aspect  of  this  effort  is  to  achieve  some  level  of 
commonality  between  the  environments  in  use  on  the  three  efforts.  Standards  have  been  taken  into 
account  in  this.  Point  of  contact:  Ed  Evers,  General  Dynamics  Data  Systems  Division,  12101 
Woodcrest  Executive  Drive,  P.O.  Box  27366,  St.  Louis,  MO  63141,  (314)851-8910. 

NASA  Space  Station 

(See  NASA  section  in  5.1) 
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ARCADIA 

The  ARCADIA  project  is  staffed  by  a  number  of  participants  from  various  organizations, 
including  universities  and  companies,  and  is  funded  by  DARPA.  Its  objective  is  to  bring  together  many 
of  the  more  modem  environment  concepts  in  order  to  provide  advancement  in  the  PSE  area.  Point  of 
contract:  Dr.  Richard  Taylor,  Department  of  Information  and  Computer  Science,  University  of 
California,  Irvine,  CA  92717,  (714)856-6429. 

EIS 

The  Engineering  Information  Station  (EIS)  is  a  project  at  AFWAL  whose  goal  is  to  provide  a 
workstation  for  the  management  of  (hardware)  engineering.  Its  concepts  and  results  are  very  much  in 
time  with  the  goals  of  the  PSE.  One  aspect  of  the  project  is  the  establishment  and  promotion  of 
relevant  standards.  In  addition  to  AFWAL  and  Honeywell,  contributing  organizations  include  Xerox, 
TRW,  MDAC,  CLSI,  and  ASU.  Point  of  contact:  Cliff  Erickson,  Honeywell,  (612)782-74%. 

ALS/N 

The  ALS/N  (Ada  Language  System  /  Navy)  is  the  Ada  compilation  capability  being 
developed  for  the  Navy  standard  computers.  The  compilation  capability  is  a  part  of  a  complete 
environment  and  is  one  environment  in  use  in  the  Navy  today.  Point  of  contact:  Bill  Wilder,  U.S.  Navy, 
NAVSEA  PMS-412,  Washington,  D.C.  20362-5101,  (703)602-8204. 

5.3  Related  Technology 

NASEE 

NASEE  is  a  NAVAIR  project  whose  objective  is  to  address  some  of  the  near-term  needs  of 
PSEs  for  NAVAIR  systems.  During  its  first  phase,  it  has  competitively  selected  a  set  of  commercial 
tools  which  deal  with  aspects  other  than  generating  code  and  made  them  available  throughout  the 
NAVAIR  laboratories  as  part  of  a  common  buy.  Future  plans  include  addressing  questions  such  as 
integration  and  transition  into  full  environments.  Point  of  contact:  John  Bergey,  NADC,  Code  703, 
Warminster,  PA  18974-5000  (215)441-3298. 

Atherton  Backplane 

Atherton  Technology  has  developed  an  integrated  set  of  services  oriented  around  a  framework 
concept.  That  framework,  both  in  concept  and  in  detail,  may  have  some  applicability  to  the  NGCR 
PSE.  Point  of  contact:  Bill  Paseman,  Atherton  Technology,  1333  Bordeaux  Drive,  Sunnyvale,  CA 
94089,  (408)734-9822. 

Methods 

Many  different  groups  are  working  on  various  methods  (and  often  tools  to  implement  them) 
that  address  some  part  of  the  full  spectrum  of  lifecycle  support.  Although  there  are  far  too  many  to  list 
individually  here,  such  efforts  may  have  some  bearing  on  the  directions  taken  for  PSE  interface 
standardization. 

Software  Process 

In  the  last  few  years,  a  new  area  of  research  in  PSEs  has  involved  the  better  definition  of  the 
software  process  which  PSEs  are  intended  to  support.  As  with  the  methods,  there  are  too  many  such 
efforts  to  list  here,  but  they  are  sure  to  play  an  important  role  in  determining  the  sort  of  PSE  needed 
to  support  those  that  are  emerging. 
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5.4  Interface  Standards 

CAIS 

The  Common  Ada  Programming  Support  Environment  (APSE)  Interface  Set  (CAIS)  (MIL- 
STD-1838A)  is  a  set  of  Kernel  APSE  (KAPSE)  level  interfaces  designed  to  provide  a  portability 
base  for  tools  written  in  Ada.  It  is  in  the  form  of  Ada  packages.  The  CAIS  provides  services  for  a  typed 
object  management  system,  process  management  (including  transactions)  and  various  levels  of 
input /output.  Point  of  contact:  Duston  Hayward,  Code  411,  NOSC,  San  Diego,  CA  92152-5000, 
(619)  553-4067. 

Portable  Common  Tool  Environment  (PCTE) 

PCTE  is  a  European  product  very  similar  in  nature  to  CAIS.  It  addresses  the  same  level  of 
interface  and  the  same  sorts  of  concerns.  Originally  developed  by  an  industry  consortium,  it  has 
become  the  target  of  standardization  by  the  European  Computer  Manufacturers  Association  and  has 
been  adopted  and  enhanced  by  a  group  of  European  MODs.  Point  of  contact:  Ken  Hayter, 

CCR,  N132,  Royal  Signals  and  Radar  Establishment,  St.  Andrews  Road,  Great  Malvern,  Worcs  WR14 
3PS,  United  Kingdom,  +44-(0684)-895836. 

Portable  Common  Interface  Set  (PCIS) 

PCIS  is  a  project,  in  its  first  stages  of  organization,  whose  objective  is  to  achieve  a  merger  of 
CAIS  and  PCTE  (described  above).  It  enjoys  the  participation  of  most  of  the  NATO  nations.  It  is 
expected  that  PCIS  will  provide  a  smooth  transition  from  either  CAIS  or  PCTE  for  organizations 
which  make  a  commitment  now  to  either  of  those.  A  new  specification  is  targeted  for  completion 
during  FY94.  Point  of  contact:  Currie  Colket,  AJPO,  (703)614-0209  or  Ken  Hayter  (listed  above  for 
PCTE). 


Portable  Operating  System  for  Computer  Environments  (POSIX) 

IEEE  Standard  1003,  IEEE  Standard  Portable  Operating  System  for  Computer 
Environments,  is  an  attempt  to  define  a  standard  operating  system  interface  and  environment  based 
on  the  UNIX  Operating  System.  They  are  to  develop  documentation  to  support  application  portability 
at  the  source  level.  This  is  intended  for  systems  implementers  and  applications  software 
implementers.  There  are  several  subgroups  within  IEEE  Standard  1003  considering  issues  such  as 
security,  real-time,  verification  and  Ada  interfaces.  POSIX  is  steadily  expanding  to  address  a  wise 
variety  of  computer  system  needs,  based  largely  on  a  concept  of  profiling  which  provides  the 
framework  for  bringing  together  number  of  complementary  standards  to  fulfill  the  needs  of  some 
particular  application  area.  Among  the  profiles  currently  identified  and  being  pursued  is  one  for 
"software  development  environments".  Point  of  contact:  Roger  Martin,  NIST,  Building  225,  Room 
8266,  Gaithersburg,  MD  20899,  (301)975-3295. 
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